Managing content

In the Content Designer tool, select Manage content and select the content folder in which you want to create the content record. From the toolbar, choose New > Website Content to create a new content record. Select a content record and choose Edit to change an existing content record, or choose Organize > Delete to delete an existing content record. There are five basic parts to creating a content record, which should be performed roughly in the following order.

Note: All content records in the Core Sites and Sample Websites content folders are protected as System content records and cannot be edited or deleted. If you want to update a System content record, create a copy of it, and then edit the copy. Be sure to also update any navigation items or shortcuts that point to that content record.

2. Add one or more iParts to each iPart zone by clicking the add content link.

3. Configure each iPart to define its individual content. (If you are changing an existing content record, you do this by clicking the triangle button at the right of the iPart's title bar and choosing Configure.)

5. If the parent content folder has been enabled for content authoring workflow, you can optionally change the default settings in the Workflow Management section, such as specifying a different content owner or different expiration behavior.

You can also click and drag iParts to rearrange them within an iPart zone or between different iPart zones. It's also possible to copy or move existing iParts from one content record to another.

When you first create a content record, or when you make changes to an existing Published content record, that particular version of the content record is not visible on any CM websites until it is published. You have two publishing options:

■ Save and publish immediately: Before closing the content record, select Save and Publish to make your changes immediately visible on all websites that use it.

■ Save, then publish later: If you Save the content record without publishing, the content record is marked with a status of Working. To publish the content record, select it and then click Publish from the Document System toolbar.

After publishing your content record, the status changes briefly to PublishPending, and then to Published once it has been fully rendered to an .aspx file on all web servers that host the relevant CM websites.

From the content record that contains the iPart that you want to move or copy, click the triangle button at the right of the iPart's title bar and choose Copy To or Move To as desired. Use the window that appears to specify the content record into which you want to copy or move the iPart.

You can move content records into different content folders by dragging and dropping them into a different folder. You can also move content records by selecting them, then using the toolbar commands Organize > Cut and Organize > Paste.

You can copy content records into other content folders by selecting them, then using the toolbar commands Organize > Copy and Organize > Paste.

When you move or copy a content record into a new content folder, you must re-publish it to make sure that the content record is made visible on all websites associated with the new content folder (and removed from all websites that were associated with the old content folder).

When you move or copy a content record that was originally in a workflow-enabled content folder (a CAG is assigned to the content folder) into another workflow-enabled folder, the content record's assigned content owner remains unchanged if the new folder's CAG also lists that person as a member and that person has Content Editor CAG permissions in the new folder's CAG. If either of these conditions are false, then the assigned Default Owner of the CAG assigned to the new content folder is assigned as the new content owner for this instance of the content record.

The tags inherited from ancestors in the content folder hierarchy are recalculated based on the content record's new position in the hierarchy. Although the new inherited tags are visible immediately within the Content Designer tool, website searches for these tags will not find the content records until you republish them.

Every time you publish a content record, the previously published version is saved as an Archived version. You can revert to an older archived version by selecting the content record, then from the toolbar choose Versions. In the resulting window, select an archived version and click Revert.

The version you selected is turned into a new Working version at the top of the list (all the previous versions remain intact). When you close the window, this is the version you'll now see in the content folder. As with any Working content record, you can publish it when you are ready to push it to your CM websites.

Content records in a workflow-enabled content folder can be set to expire a certain number of days after they were last published. The content record's assigned content owner receives several email notifications (and corresponding entries in their Content Designer Task List) just before a content record is due to expire, when it expires, and even once or twice after it has expired if the system has not automatically deleted the content record upon expiration. (For more information, refer to Fields: setup - workflow.)

If you receive notice of an upcoming expiration, you can prevent the content record from expiring by opening your Content Designer Task List and clicking the content record's title in the expiration notice. From the toolbar of the resulting window, choose Publish. This republishes the content record, which effectively restarts the expiration clock.

When a content record expires and the Automatically delete expired content? checkbox is selected in the Workflow Management section of the content record's definition, the system automatically sets the content record's status to Recycled, moves the content record to the Recycle Bin, and removes the corresponding rendered .aspx file from IIS on all web server hosts to which the content record has been published.

However, if the Automatically delete expired content? checkbox is not selected, then when a content record expires, nothing happens at all until the content owner selects the expiration notice in their Content Designer Task List and clicks Delete Selected. This sets the content record's status to Recycled, moves the content record to the Recycle Bin, and removes the corresponding .aspx file from all web servers.

A content record that has expired and been deleted automatically (or that has been manually deleted by using the Organize > Delete command on the Document System toolbar or by using the Delete Selected button on a CAG member's Content Designer Task List) is moved to the Recycle Bin at the bottom of the content folder hierarchy.

■ To permanently purge specific content records, select them in the Recycle Bin, then from the toolbar choose Organize > Purge.

■ To permanently purge all items in the Recycle Bin, select the Recycle Bin, then from the toolbar choose Organize > Empty the Recycle Bin.

■ To restore a deleted content record, select it, then from the toolbar choose Versions. In the version history that appears, click the Recycled version at the top of the list (or the desired earlier version) and click Revert. The content record is moved to its original content folder and its status changes to Working. You must re-publish the content record to create a rendered version again on all associated CM websites.

Note: If the content record's original parent folder no longer exists (or is in the Recycle Bin), the restored content record is placed in the root folder (@) of the tree. You must move it into an appropriate content folder before you can publish the content record.

■ You can also edit content records by using the Surf-to-Edit feature. Casual and Public users cannot perform the tasks described here because they cannot access Content Management. However, they can use the Surf-to-Edit feature to revise existing content records.

■ You must have some or all of the following content authority group (CAG) permissions in at least one CAG to which you belong:

□ To create or edit content records, you must have Content Editor CAG permissions.

□ To publish content records without needing approval from another person, you must have Content Approver CAG permissions. Without these permissions, you will see a Submit command (instead of a Publish command) in the Document System toolbar, which submits a publishing request to all Content Approvers defined in the system.

□ To delete content records without needing approval from another person, you must have Content Approver CAG permissions, and you must have Delete Document System permissions for each content record. Without these permissions, you will see an Organize > Request Delete command in the Document System toolbar, but it will only submit a deletion request to all Content Approvers defined in the system. You must also have Content Approver CAG permissions to use the Organize > Cut command, because this action effectively deletes the content record from its current content folder.

■ You must have both Read and Edit Document System permissions on each content folder in which you create new content records. To edit existing content records, you must have both Read and Edit Document System permissions on each content record. To delete content folders, you must have Delete Document System permissions on each content folder. The Document System permissions from the parent content folder are copied into each newly created content record, but can be changed later.

■ You must have Select Document System permissions on each content record to which you assign tags.

■ With the help of the people who perform website management, you must determine in which content folder to create the content record. Every content folder specifies important criteria that defines how the system should manage content and automatically applies these criteria to the content records created in that content folder. For example, the content folder specifies which CM websites the content records will be published to, and also specifies the CAG that determines the default workflow for the content records, such as who is notified when a content record nears its expiration date.

■ You should not create content records in the root content folder (the @ folder). It is generally unwise to specify system management criteria for content folders at the root level of the content folder hierarchy, because these criteria would be copied into all new content folders. By leaving the system default values intact in the root content folder, the people who perform website management can design a more flexible authoring and publishing environment.

■ Modifications to your master pages may be required if iParts appear to overflow the boundaries of iPart zones in the rendered pages. In general, this requires modifying the template's master page and accompanying CSS files to make the Home page and interior page layouts larger than their default size.

Note: Membership in the SysAdmin security role effectively grants the full set of Document System permissions and the full set of CAG permissions (you are effectively a member of a MasterAdmin CAG too). However, to participate in web content authoring workflow, even members of the SysAdmin role must be an explicitly-listed member of at least one CAG.

Note: The Core Content content folder and all of its descendant content folders and content records are protected for use by iMIS. The default Document System permissions for these content folders and content records permit editing only by members of the SysAdmin role.

External web-based search engines such as Google generally index the text that you specify in the Description/Summary field, and they generally ignore the keywords that you specify in the Keywords/Metatags field. The CM search engine, by contrast, looks in both of these fields for matches to the keywords specified in the search.

These two fields both generate <META> elements in the source code for a rendered content record, which are used by search engines to index pages and weight search results. The subject of <META> elements and search engines is extremely complex and has spawned its own industry of consultants, but the Search Engine Watch website includes tips for optimizing your <META> elements for search engines.

When choosing the tags to include in the configuration of an AdvancedSearch or ContentTaggedList iPart, you must account for the effect of implied relationships between parent and child tags in the tag hierarchy. A tag's position in the tag hierarchy creates an underlying relationship that is not specifically displayed in the Related Tags section: parent tags are implicitly related to their children tags with a more broadly defines relationship, and children tags are implicitly related to their parent tag with a further defines relationship. This means that:

□ The pre-filtered result set of a basic or advanced search includes all published content records that are tagged with any descendant of the tag that is matched by the search keywords.

□ The pre-filtered result set of an advanced search includes all published content records that are tagged with any descendant of a tag that is specified in the configuration of the AdvancedSearch iPart if the user selects that tag at runtime on the rendered page that contains the advanced search form.

□ The pre-filtered result set of a rendered ContentTaggedList iPart also includes published content records that are tagged with any descendent of a tag that is specified in the configuration of the ContentTaggedList.

□ The content of the Items by Tag report (in Content Management > Reports) does not list published content records that are tagged with any descendant of each tag in the report.